Are you sure this belongs in the language specification? If it is a limitation of the current implementation, it should be clearly noted that these restrictions will go away in the future.

@CyberShadow To explain about language/implementation limitation is much better than nothing is written. I'm placed the description under the "Limitation" section.

On the other hand, I don't know the limitation can be surely resolved in the future. See issue 5710 for the detailed discussion.

I'm placed the description under the "Limitation" section.

Sorry, didn't see that. Thanks.

On the other hand, I don't know the limitation can be surely resolved in the future. See issue 5710 for the detailed discussion.

Thanks, that was insightful. But I do not see any conceptual problems:

• The issues I brought up dealt with alias parameters, not delegates. As it has been suggested in that discussion, for now the issue can be solved just for alias parameters, leaving multi-context delegates alone.
• Regarding multi-context delegates, I agree with the last two comments in the discussion.

The issues I brought up dealt with alias parameters, not delegates. As it has been suggested in that discussion, for now the issue can be solved just for alias parameters, leaving multi-context delegates alone.

Current ABI specification describes that member functions and nested functions are called by exactly same call convention, and it is strongly tied to the delegate object memory layout. That is why fixing alias parameter issue will change the delegate memory layout.

Sorry if I wasn't clear - I meant to delay solving the problem of taking the address of a function with multiple context pointers. Calling the function directly can use any calling convention that the implementation wants. This will also be an opportunity to improve the error message: e.g. when you try to take the address of such a function, the compiler could say:

'S.f!(T.a)' needs 2 context pointers to 'S', 'T' - multi-context delegates are not implemented

BTW, in the original issue I brought up the function was getting called in CTFE, so there it's not even a question of codegen, just semantics.

LGTM, please rebase

Why close the pull though?

Why close the pull though?

I didn't mean to.

otherwise lgtm at least for now

Thanks for many corrections. Updated.

Thanks!